Technometria: AJAX Progress and Challenges

Phil Windley interviews Ben Galbraith, Bruce Grant, and Scott C. Lemon.

This is an audio show, around an hour in length, and since the topic isn't directly programming language related, I was not sure if I should post the link here. Still, we have been fairly quiet recently, and this show suggests some project ideas that may interest language hackers, so you might want to listen in.

Among the ideas I spotted are: JIT for Javascript, better debugging support for Javascript (possibly via an open standard for getting debug information from the javascript engine) and better ways to handle failure in web services orchestration.

This is related to previous discussions of what might be called the Web 2.0 programming model. See, for example, the discussion of the Google Web Toolkit, my suggestions about a google DSL here , Microsoft Atlas, and the various discussions about Ruby on Rails.

Closures for Java or money back

Joel Spolsky in Can Your Programming Language Do This? (Aug 1, 2006):

Java required you to create a whole object with a single method called a functor if you wanted to treat a function like a first class object. Combine that with the fact that many OO languages want you to create a whole file for each class, and it gets really klunky fast. If your programming language requires you to use functors, you're not getting all the benefits of a modern programming environment. See if you can get some of your money back.

Bracha, Gafter, Gosling, and Ahé in Closures for Java (Aug 18, 2006):

Modern programming languages provide a mixture of primitives for composing programs. C#, Javascript, Ruby, Scala, and Smalltalk (to name just a few) have direct language support for function types and inline function-valued expression, called closures. A proposal for closures is working its way through the C++ standards committees as well. Function types provide a natural way to express some kinds of abstraction that are currently quite awkward to express in Java. For programming in the small, closures allow one to abstract an algorithm over a piece of code; that is, they allow one to more easily extract the common parts of two almost-identical pieces of code. For programming in the large, closures support APIs that express an algorithm abstracted over some computational aspect of the algorithm. We propose to add function types and closures to Java. We anticipate that the additional expressiveness of the language will simplify the use of existing APIs and enable new kinds of APIs that are currently too awkward to express using the best current idiom: interfaces and anonymous classes.

LASER Summerschool

As far as I know the LASER Summerschool has not been mentioned on LTU yet.

We have a fine lineup of speakers, including Miguel de Icaza(who gave a great presentation at the Lang .NET symposium), Andreas Zeller whose book on debugging is an instant classic, Mary Poppendieck whose presentations were the highlight of last year's JAOO, Ralf Back who as usual will ensure sound foundations, and of course Bertrand Meyer who needs no introduction!

Registration is open until August 31.

I hope to see many of you in person on Elba.

Decomposing lambda - the Kernel language

The Kernel Programming Language, by John N. Shutt:

Kernel is a conservative, Scheme-like dialect of Lisp in which everything is a first-class object.

"But," you may ask, "aren't all objects first-class in Scheme?" (I'm glad you asked.) No, they aren't. Special-form combiners are second-class objects. To borrow a phrase from the original description of first- and second-class objects by Christopher Strachey, they have to appear in person under their own names. (There are also several other kinds of second-class objects in Scheme, but special-form combiners are the most commonplace.)

The idea of first-class operative combiners, i.e., first-class combiners whose operands are never evaluated, has been around a long time. Such creatures were supported by mainstream Lisps through the 1970s, notably under the name FEXPRs, but they made a mess out of the language semantics because they were non-orthogonal to the ordinary variety of procedures constructed via lambda.

Kernel eliminates the non-orthogonality problem by breaking the classical lambda constructor into two orthogonal parts, one of which is the Kernel constructor for first-class operatives.

Via Shriram Krishnamurthi on c.l.scheme. The story title is from an older paper on Kernel.

Early retirement?

Are all the editors on vacation, or is this a case of mass early retirement?

It has been awhile since we had a decent curry-howard story, but at this point I am sure any good link you have lying around is going to be appreciated.

Lisp Machine Manual

This is a prerelease version of the hypertext edition of the 6th edition of the Lisp Machine Manual. To read this manual, you need to use a browser that is capable of performing XSL transformations (Firefox, Internet Explorer and others).

A 1984 document by Richard Stallman, Daniel Weinreb and David Moon.

The preface contains a "personal note" from Stallman announcing GNU.

Some sections of interest are: cdr coding, closure manipulation functions, stack groups, and areas.

Programming Languages in the Markup World

The Extreme Markup 2006 conference has finished and the proceedings are up. If you have any interest in the intersection of programming and markup languages, there were a few papers worth looking at. Here's my choice:

Revisiting Google's MapReduce

Google's MapReduce Programming Model -- Revisited. Ralf Lämmel.

MapReduce is a programming model (and an associated implementation) used at Google for processing large amounts of input data (such as millions of documents) and generating keyed or indexed query results (such as the indexes used for Google's web search). The programming model is stunningly simple, and it allows the programmer to largely abstract from the parallel and distributed execution of the data-processing computations. Parallel execution is promoted by the assumed skeleton of MapReduce computations. Load balancing, network performance and fault tolerance are taken care of by the MapReduce implementation.

We revisit the MapReduce programming model in an attempt to provide a rigorous description of the model. We focus on the key abstraction for MapReduce computations; this abstraction is parameterized by the problem-specific ingredients for data extraction and reduction. We use Haskell as a lightweight specification language to capture the essence of MapReduce computations in a succinct, executable and strongly typed manner. Our study substantiates that clarity, generality and correctness of designs (or the presentations thereof) are easily improved, if modest functional programming skills are put to work.

This is a fun example of type-directed exploration and prototyping, and pokes some gentle fun of Google's (ab)use of standard terminology. It's neat to get a glimpse into the programming process of a very experienced Haskell programmer.

(From the forums.)

Comonadic Functional Attribute Evaluation

Comonadic Functional Attribute Evaluation. Tarmo Uustalu and Varmo Vene.

We have previously demonstrated that dataflow computation is comonadic. Here we argue that attribute evaluation has a lot in common with dataflow computation and admits a similar analysis. We claim that this yields a new, modular way to organize both attribute evaluation programs written directly in a functional language as well as attribute grammar processors.

(This is an extended abstract. I believe a longer version is here, but I haven't read it.)

We've previously seen The Essence of Dataflow Programming, and in one sense this is a follow-up. Applying comonads to dataflow programming was not uncritically accepted as being "essential," as I recall. For attribute grammars, this approach seems elegant enough from a casual read, but they don't offer a detailed comparison with prior work on attribute grammars, and I'm nowhere near familiar enough to judge for myself.

Whether or not this is a significant step forward in that sense, it certainly has some nice examples of comonads. There's also this claim:

This does not seem to have been mentioned in the literature, but the type constructor CxtTree E is a comonad (just as LS is; in fact, the same is true of all zipper type constructors).

(Emphasis mine.) This seems to be a relatively well-known fact about zippers, but perhaps not?

CellML

The CellML language is an open standard based on the XML markup language. CellML is being developed by the Bioengineering Institute at the University of Auckland and affiliated research groups.

The purpose of CellML is to store and exchange computer-based mathematical models. CellML allows scientists to share models even if they are using different model-building software. It also enables them to reuse components from one model in another, thus accelerating model building.

Although CellML was originally intended for the description of biological models, it has a broader application (for an example, see the Mooney-Rivlin Constitutive Material Law). CellML includes information about model structure (how the parts of a model are organizationally related to one another), mathematics (equations describing the underlying processes) and metadata (additional information about the model that allows scientists to search for specific models or model components in a database or other repository).

An interesting XML based DSL, with a strong visual programming layer. I don't think we mentioned it in the past, and I'll be happy to hear what people here think of it.

For the recored, I am speaking at the annual conference of the open source community here in Israel, this Friday. My talk is about e-learning, and cellML is one of the examples I am going to discuss.